The OP-TEE driver registers the function notif_callback() for FF-A
notifications. However, this function is called in an atomic context
leading to errors like this when processing asynchronous notifications:

 | BUG: sleeping function called from invalid context at kernel/locking/mutex.c:258
 | in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 9, name: kworker/0:0
 | preempt_count: 1, expected: 0
 | RCU nest depth: 0, expected: 0
 | CPU: 0 UID: 0 PID: 9 Comm: kworker/0:0 Not tainted 6.14.0-00019-g657536ebe0aa #13
 | Hardware name: linux,dummy-virt (DT)
 | Workqueue: ffa_pcpu_irq_notification notif_pcpu_irq_work_fn
 | Call trace:
 |  show_stack+0x18/0x24 (C)
 |  dump_stack_lvl+0x78/0x90
 |  dump_stack+0x18/0x24
 |  __might_resched+0x114/0x170
 |  __might_sleep+0x48/0x98
 |  mutex_lock+0x24/0x80
 |  optee_get_msg_arg+0x7c/0x21c
 |  simple_call_with_arg+0x50/0xc0
 |  optee_do_bottom_half+0x14/0x20
 |  notif_callback+0x3c/0x48
 |  handle_notif_callbacks+0x9c/0xe0
 |  notif_get_and_handle+0x40/0x88
 |  generic_exec_single+0x80/0xc0
 |  smp_call_function_single+0xfc/0x1a0
 |  notif_pcpu_irq_work_fn+0x2c/0x38
 |  process_one_work+0x14c/0x2b4
 |  worker_thread+0x2e4/0x3e0
 |  kthread+0x13c/0x210
 |  ret_from_fork+0x10/0x20

Fix this by adding work queue to process the notification in a
non-atomic context.

Fixes: d0476a5 ("optee: ffa_abi: add asynchronous notifications")
Cc: [email protected]
Reviewed-by: Sumit Garg <[email protected]>
Tested-by: Sudeep Holla <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jens Wiklander <[email protected]>

The commit 86bc882 ("staging: vchiq_arm: Create keep-alive thread
during probe") introduced a regression for certain configurations,
which doesn't have a VCHIQ user. This results in a unused and hanging
keep-alive thread:

  INFO: task vchiq-keep/0:85 blocked for more than 120 seconds.
        Not tainted 6.12.34-v8-+ #13
  "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
  task:vchiq-keep/0    state:D stack:0 pid:85    tgid:85    ppid:2
  Call trace:
   __switch_to+0x188/0x230
   __schedule+0xa54/0xb28
   schedule+0x80/0x120
   schedule_preempt_disabled+0x30/0x50
   kthread+0xd4/0x1a0
   ret_from_fork+0x10/0x20

Fixes: 86bc882 ("staging: vchiq_arm: Create keep-alive thread during probe")
Reported-by: Maíra Canal <[email protected]>
Closes: https://lore.kernel.org/linux-staging/[email protected]/
Cc: [email protected]
Signed-off-by: Stefan Wahren <[email protected]>
Reviewed-by: Maíra Canal <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>

[ Upstream commit 163e5f2 ]

When using perf record with the `--overwrite` option, a segmentation fault
occurs if an event fails to open. For example:

  perf record -e cycles-ct -F 1000 -a --overwrite
  Error:
  cycles-ct:H: PMU Hardware doesn't support sampling/overflow-interrupts. Try 'perf stat'
  perf: Segmentation fault
      #0 0x6466b6 in dump_stack debug.c:366
      qualcomm-linux#1 0x646729 in sighandler_dump_stack debug.c:378
      qualcomm-linux#2 0x453fd1 in sigsegv_handler builtin-record.c:722
      qualcomm-linux#3 0x7f8454e65090 in __restore_rt libc-2.32.so[54090]
      qualcomm-linux#4 0x6c5671 in __perf_event__synthesize_id_index synthetic-events.c:1862
      qualcomm-linux#5 0x6c5ac0 in perf_event__synthesize_id_index synthetic-events.c:1943
      qualcomm-linux#6 0x458090 in record__synthesize builtin-record.c:2075
      qualcomm-linux#7 0x45a85a in __cmd_record builtin-record.c:2888
      qualcomm-linux#8 0x45deb6 in cmd_record builtin-record.c:4374
      qualcomm-linux#9 0x4e5e33 in run_builtin perf.c:349
      qualcomm-linux#10 0x4e60bf in handle_internal_command perf.c:401
      qualcomm-linux#11 0x4e6215 in run_argv perf.c:448
      qualcomm-linux#12 0x4e653a in main perf.c:555
      qualcomm-linux#13 0x7f8454e4fa72 in __libc_start_main libc-2.32.so[3ea72]
      qualcomm-linux#14 0x43a3ee in _start ??:0

The --overwrite option implies --tail-synthesize, which collects non-sample
events reflecting the system status when recording finishes. However, when
evsel opening fails (e.g., unsupported event 'cycles-ct'), session->evlist
is not initialized and remains NULL. The code unconditionally calls
record__synthesize() in the error path, which iterates through the NULL
evlist pointer and causes a segfault.

To fix it, move the record__synthesize() call inside the error check block, so
it's only called when there was no error during recording, ensuring that evlist
is properly initialized.

Fixes: 4ea648a ("perf record: Add --tail-synthesize option")
Signed-off-by: Shuai Xue <[email protected]>
Signed-off-by: Namhyung Kim <[email protected]>
Signed-off-by: Sasha Levin <[email protected]>